home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0332.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  2.0 KB  |  48 lines
  1.  
  2. >As I understand it, the distinction between an indexed document
  3. >and an ordinary one is that an indexed document is really
  4. >an abstract document.   Once you provide the index terms,
  5. >then it is concrete document.  So a Dictionary is abstract
  6. >until I send it a keyword, then I get back a real document,
  7. >the definition for the word.
  8.  
  9. The most useful definition of a document I've seen is "a unit
  10. of retreival." Since you can't retrieve the index -- only
  11. summaries of the index, query results from the index, etc. --
  12. the index isn't a document by that definition.
  13.  
  14. >In the case of the dictionary, of course, one could argue
  15. >that the Dictionary as a whole is also a concrete document,
  16. >since it would be possible to just read it cover to cover.
  17.  
  18. If we had a protocol to do this, yes...
  19.  
  20. >Maybe this can be addressed in HTML2, by some process of negotiation
  21. >between server (abstract document) and user/client.  e.g the document
  22. >sends something back saying "I will give you a page of text but
  23. >first send me at least one line of ascii".  If this is the
  24. >right approach, then we need a means of describing data types and prompts.
  25. >The negotiation might take several exchanges, or it might be done
  26. >by having the server return a small program, something like a decision
  27. >tree, to prompt the user for all meaningful values required for
  28. >the input.
  29.  
  30. Clarification: this shouldn't impact HTML significantly. It should
  31. impact HTTP, the protocol. Whether the forms description/query
  32. language should become part of HTML isn't clear. I'd say: no, it
  33. should be a separate beast.
  34.  
  35. Tim mentioned the same scenario, with servers sending out forms,
  36. clients with "forms editors" and complex queries.
  37.  
  38. The closest thing I've seen to an implementation of this is the
  39. Dynatext browser. There's some sort of query dialog description
  40. language: I think it's an SGML language. So you describe the dialog
  41. with an SGML document. The browser displays toggle buttons, text
  42. fields etc. The user fills in the fields, clicks OK, and the
  43. query results come up in the table of contents window.
  44.  
  45. Dan
  46.  
  47.  
  48.